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Foreword 



This GSM Technical Specification has been produced by the Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This specification gives the stage 2 description of the Completion of Calls to Busy Subscriber (CCBS) supplementary 
service within the digital cellular telecommunications system. 

The contents of this specification are subject to continuing work within SMG and may change following formal SMG 
approval. Should SMG modify the contents of this specification it will then be re-issued with an identifying change of 
release date and an increase in version number as follows: 

Version 6.x.y 

where: 

6 GSM Phase 2+ Release 1997 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc.; 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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1 Scope 



This Technical Specification gives the stage 2 description of the Completion of Calls to Busy Subscriber (CCBS) 
supplementary service. 



Normative references 



References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 
acronyms". 

[2] GSM 02.30: "Digital cellular telecommunications system (Phase 2+); Man Machine Interface 

(MMI) of the Mobile Station (MS)". 

[3] GSM 02.93: " Digital cellular telecommunications system (Phase 2+); Completion of calls to busy 

subscriber (CCBS) supplementary services - Stage 1". 

[5] GSM 03.1 1: "Digital cellular telecommunications system (Phase 2+); Technical realization of 

supplementary services". 

[6] GSM 03.18: "Digital cellular telecommunications system (Phase 2+); Basic Call Handling - 

Technical Realization". 

[7] GSM 03.78: "Digital cellular telecommunications system (Phase 2+); Customised Applications for 

Mobile network Enhanced Logic (CAMEL) - Stage 2". 

[8] GSM 03.79: "Digital cellular telecommunications system (Phase 2+); Support for Optimal 

Routeing (SOR) - Technical Realization". 

[9] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

layer 3 specification". 

[10] GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part 

(MAP) specification". 

[II] ETS 300 358: "ISDN Completion of Calls to Busy Subscriber (CCBS) supplementary service; 
Functional capabilities and information flows". 



GSM 03.93 version 6.1 .0 Release 1 997 7 TS 1 01 283 V6.1 .0 (1 998-07) 



Definitions and abbreviations 



3.1 Definitions 



Destination B: The entity addressed in the original call set up, which is busy when first called by subscriber A. 
Similarly, MSC B, VLR B and HLR B are the network elements pertaining to Destination B when Destination B is a 
GSM mobile. 

Originating queue: The queue that manages CCBS requests for a subscriber, when that subscriber is the originator of 
those CCBS Requests. 

SSAP: Supplementary Service Application Part. SSAP is the protocol used for CCBS procedures on the interface 
between the originating and destination network. Communication across this interface is performed using SCCP 
Connectionless SignalUng (Refer to ETS 300 358). 

Subscriber A: The user of MS A, requesting CCBS. Similarly, MSC A, VLR A and HLR A are the network elements 
pertaining to Subscriber A. 

Subscriber B: The user of destination B, who may not necessarily subscribe to CCBS. 

Subscriber C: The user of MS C, who is the forwarded-to-party when call forwarding applies. Similarly, MSC C, VLR 
C and HLR C are the network elements pertaining to Subscriber C. 

Target queue: The queue that manages CCBS requests for a subscriber, when that subscriber is the target of CCBS 
Requests. 

Timers: For each of the service timers, the location, start and stop conditions and action on expiry are given - Refer to 
subclause 5.L 

3.2 Abbreviations 

Abbreviations used in this specification are listed in GSM 0L04. 



4 General 

4.1 Overview 

The CCBS service allows a calling subscriber A, encountering a NDUB destination B, to be notified when destination B 
becomes idle and to have the network automatically generate a CCBS call to destination B, if subscriber A desires. 
Subscriber A may make distinct CCBS requests for calls to the same destination B for different basic services. 

4.2 Architecture 

Figure 4.2. 1 is an architectural overview of the CCBS service when interworking between the originating and the 
destination networks involved. The originating network may be a mobile network or a fixed network and the destination 
network may also be a mobile network or a fixed network. 

The call related signalling for CCBS is performed on ISUP links on the following interfaces: 

VMSC A - GMSC B; 

VMSC A - DLL; 
OLE - GMSC B; 
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whereas the specific CCBS procedures are performed via the SSAP protocol, which is signalled on the following 
interfaces: 

HLR A - HLR B; 

HLR A - DLE; 

OLE - HLR B. 
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Fixed 
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Mobile 
Network 



ISUP 



VMSC B 



Figure 4.2.1 : Architectural overview showing common point of interworking 



4.2.1 Architectural overview during roaming 

Either the originating subscriber A or the destination subscriber B or both may be located outside of their HPLMNs 
during the CCBS service. When all the involved networks support CCBS service the normal handling described in this 
specification applies. When some network entities do not support CCBS service refer to clause 10 where the exceptions 
are described in more detail. 

The signalling between different networks described in the subclause 4.2 applies also during roaming. HLR A and 
HLR B belongs always to the HPLMN of the subscriber whereas VLR A and MSC A and GMSC, VLR B and MSC B 
respectively may belong to a HPLMN or VPLMN. Refer to GSM 03.18 where call handling in the mobile network is 
described in more detail. 
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5 Handling of completion of calls to busy subscriber 

Registration and erasure of CCBS are not applicable. Activation and Invocation of CCBS are intrinsic parts of the 
operation of the service, and are described in this section. 



5.1 



CCBS Timers 



The timers used to control the operation of CCBS can be considered to consist of two groups i.e. the timers which 
operate on a per subscriber basis (see table 1) and the service duration timers (T3 and T7) which operate on a per CCBS 
Request basis (see table 2). 

Table 1 : CCBS Service Timers 



Timer 


Name 


Value 


Run At 


Started 


Stopped 


Expiry 


11 


Retention 


>15s 


MSCA 


Busy (CCBS Possible) 
sent to IVIS A 


CCBS Request received 
from MS A 


Discard retained 
information 


14 


Recall 


20-30S 


MSCA 


CCBS Recall sent to 
MS A and MS A is idle 


Subscriber A initiates 
CCBS setup or rejects 
CCBS Recall 


Cancel request 


18 


Destination 
idle guard 


0-1 5s 


HLRB 


Event Report received 
from VLR B indicating 
destination B is idle 


Event Report received 
from VLR B indicating 
destination B is no longer 
idle 


Inform originating 
network that 
Destination B is 
free 


19 


Recall B 


40-55S 


HLRB 


Remote User Free sent 
to the A-side 


Request cancelled, 
completed or suspended 


Cancel request 


no 


CCBS 
notification 


20-30S 


MSCA 


CCBS Recall sent to 
MS A and MS A is not 
idle 


Subscriber A initiates 
CCBS setup, rejects 
CCBS Recall or requests 
suspension 


Suspend request 


111 


CCBS resume 


20-25S 


HLRA 


HLR A receives a resume 
request and there are 
more than one 
suspended request in 
subscriber A's queue 


Remote User Free 
received from destination 
network 


Resume next 
suspended 
request in queue 


T12 


CCBS Call 
Guard 


20-30S 


HLRA 


HLRA receives a CCBS 
RUFAck and starts to 
wait CCBS Call Report 


CCBS Call Report 
received 


Cancel request 



Table 2: Service Duration Timers 



Timer 


Name 


Value 


Run At 


Started 


Stopped 


Expiry 


T3 
T7 


Originating 

service 

duration 

Terminating 

service 

duration 


15-45m 
>45m 


HLRA 
HLRB 


Acknowledgement to 
CCBS Request 
received from 
destination network 

HLR B acknowledges 
successful activation of 
a CCBS Request 


Request cancelled or 
completed 

Request cancelled or 
completed 


Cancel request 
Cancel request 
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5.2 Information flows 

Figures 5.2. 1 and 5.2.2 show the flow of information between network elements for a mobile to mobile call for the 
following: 

Figure 5.2.1: Successful CCBS request, destination B busy when request made, subscriber A free when destination B 
becomes free. 

Figure 5.2.2: Subscriber A is not idle when destination B becomes free. 

Figures 5.2.3 and 5.2.4 show the flow of information between network elements for a mobile to fixed call for the same 
situations described in figures 5.2.1 and 5.2.2 respectively. 

Each information flow diagram has been divided where appropriate into four distinct phases of operation. These are as 
follows: 

(1) Pre-conditions (Initial Call encountering NDUB and CCBS possible in the destination network). The detailed 
description of the basic call handling can be found in GSM 03.18; 

(2) Activation; 

(3) Invocation; 

(4) Operation (CCBS Call Set-up). 
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Figure 5.2.1 : Successful CCBS request. Destination B busy when request activated, subscriber A free 

when destination B becomes free (mobile-to-mobile) 
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Figure 5.2.2: Subscriber A not idle when destination B becomes free (mobile-to-mobile); 

Processing of a single request 
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Figure 5.2.3: Successful CCBS request. Destination B busy when request activated, subscriber A free 

when destination B becomes free (mobile-to-fixed) 
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Figure 5.2.4: Subscriber A not idle when destination B becomes free (mobile-to-fixed) 

5.3 Activation 

Activation of a CCBS Request is carried out by subscriber A. VLR A is considered to be transparent during the 
activation operation. 



The information flows shown in figures 5.2.1 to 5.2.4 inclusive show the information flow for the activation process. 
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5.4 Deactivation 

Subscriber A may deactivate CCBS in any of the following ways: 

Deactivate all outstanding CCBS requests; or 

Deactivate a specific CCBS Request. 
The different deactivation operations are identified by different MMI commands as specified in GSM 02.30. 
Deactivation of CCBS requests by subscriber A shall be performed at HLR A. 

To deactivate all outstanding CCBS requests, the Deactivate CCBS operation request shall contain the SS-Code only. 
To deactivate a specific CCBS request, the Deactivate CCBS operation request shall contain the following parameters: 

- SS-Code; 

- CCBS Index. 

On receipt of the deactivation request, HLR A shall cancel the CCBS request, i.e. remove all record of a CCBS request 
from the subscriber A's originating CCBS queue and instruct the destination B network to cancel the corresponding 
CCBS request in the destination CCBS queue of subscriber B. HLR A shall return a result indicating whether the 
deactivation attempt was successful or not. 



MSA 



MSCA 



VLRA 



HLR A 



Destination B 
Network 




Deactivate CCBS 



Acknowledge 



CCBS Cancel 



(note) 



NOTE: CCBS Cancel shall be sent for each CCBS Request that is cancelled in HLR A. 

Figure 5.4: Successful deactivation of all CCBS Requests/a specific CCBS request 

NOTE: In the case where a subscriber attempts to perform a deactivation operation but the subscriber is not 

provisioned with the CCBS service then, the subscriber shall receive an indication that the CCBS service 
is not provisioned for him. 
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5.5 Interrogation 



Interrogation of CCBS shall be carried by request to HLR A. HLR A then returns the required information or error to 
MS A, see figure 5.5. MSC A and VLR A are considered to be transparent during the interrogation operation. 



MSA 



MSC A 



VLR A 



HLR A 



Interrogate CCBS 



Acknowledge 





Interrogate CCBS 



Acknowledge 



Interrogate CCBS 



Acknowledge 



Figure 5.5: General interrogation of completion of calls to busy subscriber 

The Interrogate CCBS operation request shall contain the SS-Code only. 

In response to a general interrogation, MS A shall be given the AddressOfB, BasicServiceCode and CCBS index for 
each CCBS Request in the queue. The entries shall be ordered in the chronological order, the oldest entry shall be 
presented first. 

If there are no CCBS Requests in the queue, MS A shall be given an indication that no entries exist in the queue. 

NOTE: In the case where a subscriber attempts to perform an interrogation operation but the subscriber is not 

provisioned with the CCBS service then, the subscriber shall receive an indication that the CCBS service 
is not provisioned for him. 
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5.6 Messages and their contents 

This clause contains the detailed description of the information flows used by CCBS. 

Each Information Element, IE is marked as (M) Mandatory, (C) Conditional or (O) Optional. A mandatory information 
element shall always be present. A conditional information shall be present if certain conditions are fulfilled; if those 
conditions are not fulfilled it shall be absent. An optional information element may be present or absent, at the discretion 
of the application at the sending entity. This categorisation is a functional classification, i.e., stage 2 information and not 
a stage 3 classifications to be used for the protocol. 

The stage 2 and stage 3 message and information element names are not necessarily identical. 

5.6.1 Information elements used in the messages 

In this clause constructed information elements are described. 



5.6.1.1 



Call Information information element 



Call Information information element is formed in the MSC A during the CCBS activation. This information element 
contains unmodified copy of the SETUP message received from the MS A. If CCBS Request is activated, the Call 
Information is stored in the HLR A. During CCBS Recall Call Information is relayed back to the MS. Refer to SETUP 
Container information element defined in GSM 04.08. 



5.6.1.2 



AddressOfB information element 



AddressOfB information element is formed in the MSC A during the CCBS activation. It contains the number of the 
destination B dialled by the A-user. 

Table 5.6.1.2: Structure of AddressOfB information element 



Parent Information 


Child Information element 


Information 


Information element description 


Element 


name 


element 
Required 




AddressOfB 


B subscriber number. 


M 


The number of the destination B dialled by the A-user; 




B subscriber subaddress 


C 


Shall be present if it was dialled by the A-user; 
otherwise shall be absent 



5.6.1 .3 CCBS Description information element 

CCBS Description information element is formed in the HLR A during the CCBS activation. 

Table 5.6.1.3: Structure of CCBS Description information element 



Parent Information 
Element 


Child Information 
element name 


Information 
element 
Required 


Information element description 


CCBS Description 


CCBS Index, 

AddressOfB, 

BasicServiceGroup 


M 
M 
M 


CCBS Index (range 1 - 5) identifies the request in the network. 
The structure of the AddressOfB is defined in table 5.6.1.2; 
BasicServiceGroup related to the original call. 
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5.6.2 Messages between MS and MSC 

These messages are used in the originating network. 



Table 5.6.2: Messages between MS and MSC 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


CCBS POSSIBLE 


MSC 


- 


- 


This message contains no information elements. 


CCBS REQUEST 


MS 


- 


- 


This message contains no information elements. 


CCBS REQUEST 
ACK 


MSC 


CCBS Index, 

AddressOfB, 

BasicServiceGroup 


M 
O 
O 


CCBS Index (range 1 - 5) identifies the request in the 

network. 

The structure of the AddressOfB is defined in table 5.6.1.2 

BasicServiceGroup related to the original call. 


CCBS REQUEST 
ERROR 


MSC 


Error 


M 


The information element can take the following values; 

- Short term denial 

- Long term denial 


DEACTIVATE CCBS 


MS 


CCBS Index 


C 


If CCBS Index is present the corresponding request shall be 
deleted, otherwise all requests shall be deleted. 


DEACTIVATE CCBS 
ACK 


MSC 


DeactivateResult 


M 


The information element can take the following values; 

- Success 

- Not Provisioned 


INTERROGATE 
CCBS 


MS 


- 


- 


This message contains no information elements. 


INTERROGATE 
CCBS ACK 


MSC 


List(l-5)ofCCBS 

Description; 

No Entries; 

Not Provisioned 


C 
C 

c 


The list shall contain one entry for each CCBS Request for 

which the HLR stores data or; 

the queue is empty or; 

CCBS is not provisioned for the subscriber 

Exactly one of these information elements shall be present. 

The structure of the CCBS Description is defined in 

table 5.6.1.3. 


CCBS CALL INFO 


MSC 


Call Information 


M 


The content of the Call Information is defined in the 
subclause 5.6.1.1. 


CCBS CALL INFO 
ACK 


MS 


GSMBC 


M 


GSM BC indicates the BC the MS prefers to use. The network 
may allocate a traffic channel accordingly. 


CCBS CALL INFO 
ERROR 


MS 


Error 


M 


The information element can take the following values; 
- Incompatible Terminal 


CCBS RECALL 


MSC 


CCBS Description, 
Alerting Pattern 


M, 
C 


The structure of the CCBS Description is defined in 
table 5.6.1.3. 

Alerting Pattern shall be present if it was received in the 
CCBS RUE message 


CCBS SETUP 


MS 


- 


- 


The content of the message is the same as the MO Set-up 
message has. Refer to GSM 04.08. 


CCBS RECALL 
REJECT 


MS 


Cause 


M 


The MS shall indicate the reason of CCBS Recall rejection. 
The information element can take the following values; 

- Recall Rejected by the user 
-UDUB 

- ACMmax exceeded 
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5.6.3 Messages between MSC and VLR (B-interface) 



5.6.3.1 



Messages between MSC and VLR in the originating network 



These messages are used in the originating network. Some messages are used also in the terminating network. They are 
marked accordingly. 



Table 5.6.3.1 : Messages between MSC and VLR in the originating networl< 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


CALL END 


MSC 






This message contains no information elements. 
The message is used also in the terminating network. 


CCBS CALL 
DELIVERY 


MSC 


Outcome 


M 


The information element indicates whether CCBS Call was 
successful or failure. It can take the following values: 

- Success; 

- Failure; 

- NDUB; 

- Busy; 

- Absent Subscriber.. 

The message is used also in the terminating network. 


CCBS REQUEST 


MSC 


- 




This message contains no information elements 


CCBS REQUEST 
ACK 


VLR 


CCBS Index, 

AddressOfB, 

BasicServiceGroup 


M 
O 
O 


CCBS Index (range 1 - 5) identifies the request in the 

network. 

The structure of the AddressOfB is defined in table 5.6.1.2 

BasicServiceGroup related to the original call. 


CCBS REQUEST 
ERROR 


VLR 


Error 


M 


The information element can take the following values: 

- Short term denial; 

- Long term denial. 


COMPLETE 
RECALL 


VLR 


Call Information 


M 


The content of the Call Information is defined in the 
subclause 5.6.1.1. 


COMPLETE 
RECALL ACK 


MSC 


- 


- 


This message contains no information elements 


COMPLETE 

RECALL NEGATIVE 

RESPONSE 


MSC 


Negative Response 


M 


The negative information element can take the following 
values: 

- Absent Subscriber; 

- Incompatible Terminal; 

- Radio Congestion. 


DEACTIVATE CCBS 


MSC 


CCBS Index 


C 


If CCBS Index is present the corresponding request shall be 
deleted, otherwise all requests shall be deleted. 


DEACTIVATE CCBS 
ACK 


VLR 


DeactivateResult 


M 


The information element can take the following values: 

- Success; 

- Not Provisioned. 


INTERROGATE 
CCBS 


MSC 


- 


~ 


This message contains no information elements 
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Table 5.6.3.1 : Messages between MSC and VLR in the originating networl<, cont. 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


INTERROGATE 
CCBS ACK 


VLR 


List(l-5)ofCCBS 
Description; 
No Entries; 

Not Provisioned 


C 
C 

c 


The list shall contain one entry for each CCBS Request for 
which the HLR stores data; or 
the queue is empty; or 

CCBS is not provisioned for the subscriber. 

Exactly one of these information elements shall be present. 
The structure of the CCBS Description is defined in 
table 5.6.1.3. 


NOT IDLE 


MSC 


- 


- 


This message contains no information elements. The message 
is used also in the terminating network. 


PAGE MS FOR 
RECALL 


VLR 


Location area ID, 
TMSI 


M 

o 


Location area in which the MS is to be paged 
TMSI to be broadcast to identify the MS 


PAGE MS FOR 

RECALL NEGATIVE 

RESPONSE 


MSC 


Negative Response 


M 


The negative information element can take the following 
values: 

- Unknown LAI; 

- Absent Subscriber; 

- Busy Subscriber. 


PROCESS ACCESS 
REQUEST 


MSC 


- 


- 


Refer to GSM 03.18 


RADIO FAILURE 


MSC 






This message contains no information elements. 
The message is used also in the terminating network. 


RECALL 


VLR 


CCBS Description 
Alerting Pattern 


M 
C 


The structure of the CCBS Description is defined in 
table 5.6.1.3. 

Alerting Pattern shall be present if it was received in the 
CCBS RUE message 


RECALL ACK 


MSC 


Cause 


M 


The information element can take the following values: 

- Accept; 

- Rejected; 

- T4 Expiry; 

- TIO Expiry; 

- Radio Failure; 

- UDUB, busy; 

- UDUB, idle; 

- Incompatible terminal. 


SEARCH FOR MS 
MSC FOR RECALL 


VLR 


- 


- 


This message contains no information elements 


SEARCH FOR MS 

MSC FOR RECALL 

ACK 


MSC 






This message contains no information elements 


SEARCH FOR MS 

MSC FOR RECALL 

NEGATIVE 

RESPONSE 


MSC 


Negative Response 


M 


The negative information element can take the following 
values: 

- Absent Subscriber; 

- Busy Subscriber; 


SEND INFO FOR 
OUTGOING CALL 


MSC 


- 


- 


Refer to GSM 03.18 


START STATUS 
ENQUIRY 


VLR 






This message contains no information elements. 
The message is used also in the terminating network. 


STATUS ENQUIRY 
RESULT 


MSC 


Status 


M 


The information element can take the following vales: 

- CCBS Idle; 

- CCBS Not Idle. 

The message is used also in the terminating network. 


STOP STATUS 
ENQUIRY 


VLR 






This message contains no information elements. 
The message is used also in the terminating network. 
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5.6.3.2 



Messages between MSC and VLR in the destination network 



These messages are used in the destination network. Some messages are used also in the originating network. They are 
marked accordingly. 



Table 5.6.3.2: Messages between MSC and VLR in the destination network 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


CALL END 


MSC 


- 


- 


Refer to table 5.6.3.1 


CCBS CALL 
DELIVERY 


MSC 


- 




Refer to table 5.6.3.1 


START STATUS 
ENQUIRY 


VLR 


- 


- 


Refer to table 5.6.3.1 


STATUS ENQUIRY 
RESULT 


MSC 




- 


Referto table 5.6.3.1 


STOP STATUS 
ENQUIRY 


VLR 


- 


- 


Referto table 5.6.3.1 


RADIO FAILURE 


MSC 


- 


- 


Refer to table 5.6.3.1 


NOT IDLE 


MSC 


- 


- 


Refer to table 5.6.3.1 


COMPLETE CALL 


VLR 


Indicator 


C 


Refer to GSM 03.18 

In addition: 

The information element shall be present if the call is CCBS 

Call; otherwise it shall be absent. 


PROCESS CALL 

WAITING 


VLR 


Indicator 


C 


Refer to GSM 03.18 

In addition: 

The information element shall be present if the call is CCBS 

Call; otherwise it shall be absent. 


SEND INFO FOR 

INCOMING CALL 

ACK 


VLR 


CCBS Target 


c 


Refer to GSM 03.18 

In addition: 

The information element shall be present if the B subscriber 

can be target of CCBS request; otherwise it shall be absent. 


SEND INFO FOR 

INCOMING CALL 

NEGATIVE 

RESPONSE 


VLR 


CCBS Target 


c 


Refer to GSM 03.18 

In addition: 

The information element shall be present if the B subscriber 

can be target of CCBS request; otherwise it shall be absent. 
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5.6.4 Messages between VLR and HLR (D-interface) 



5.6.4.1 



Messages between VLR and HLR in the originating network 



These messages are used between VLR - HLR in the originating network. Some messages are used also in the 
destination network. They are marked accordingly. 



Table 5.6.4.1 : Messages between VLR and HLR in the originating networl< 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


CCBS REQUEST 


VLR 


Call Information 

ISDN BC 

ISDN HLC 

ISDN LLC 

Presentation Indicator 

Translated B No 

CAMEL Invoked 

Basic Service Group 

AddressOfB 


M 
M 
C 

c 

c 

M 
C 
M 
M 


The content of the Call Information is defined in the 

subclause 5.6.1.1. 

ISDN BC derived for the initial call. 

Shall be present if ISDN HLC was present in the initial call; 

otherwise shall be absent. 

Shall be present if ISDN LLC was present in the initial call; 

otherwise shall be absent. 

Shall be present if CLIR was invoked for the initial call; 

otherwise shall be absent. 

The number used for routing purposes stored in international 

E.164 format. 

Shall be present if MO CAMEL was invoked in the initial 

call; otherwise shall be absent. 

GSM Elementary Basic Service Group which corresponds to 

the basic service used for initial call set-up 

The structure of the AddressOfB is defined in table 5.6.1.2 


CCBS REQUEST 
ACK 


HLR 


CCBS Index 

AddressOfB 

Basic Service Group 


M 
O 
O 


CCBS Index (range 1 - 5) identifies the request in the 

network. 

The structure of the AddressOfB is defined in table 5.6.1.2 

BasicServiceGroup related to the original call. 


CCBS REQUEST 
ERROR 


HLR 


Error 


M 


The information element can take the following values: 

- Short term denial; 

- Long term denial; 


CCBS RUE 


HLR 


Call Information 

CCBS Description 

Translated B No 

Replace B No 

Alerting Pattern 


M 
M 
M 
C 

C 


The content of the Call Information is defined in the 

subclause 5.6.1.1. 

The content of the CCBS Description is defined in 

table 5.6.1.3. 

The number used for routing purposes in international E.164 

format. 

The information element shall be present if the HLR instructs 

the MSC to replace the destination B number with the 

translated B number; otherwise it shall be absent. 

Alerting Pattern shall be present if the HLR has determined an 
alerting category or an alerting level for the CCBS recall 


CCBS RUF ACK 


VLR 


Result 


M 


The information element indicates whether CCBS Recall was 
accepted. It can take the following values: 

- RUF Accepted; 

- RUF Rejected; 

- T4 Expiry; 

- TIO Expiry; 

- UDUB, idle; 

- UDUB, busy. 


CCBS RUF ERROR 


VLR 


Error 


M 


The information element indicates the reason why CCBS 
Recall could not be successfully delivered. It can take the 
following values: 

- IMSI Detached; 

- Restricted Area; 

- No Page Response; 

- Incompatible Terminal; 

- Absent Subscriber; 

- Radio Failure; 

- Ccomp Busy; 

- System Failure. 
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Table 5.6.4.1 : Messages between VLR and HLR in the originating networl<, cont. 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


EVENT REPORT 


VLR 


Status 


M 


The information element contains subscriber status. It can take 
the following values: 

- CCBS Idle; 

- CCBS Not Idle; 

- CCBS Not Reachable. 

The message is used also in the terminating network. 


EVENT REPORT 
ACK 


HLR 






This message contains no information elements 
The message is used also in the terminating network. 


EVENT_REPORT_ 
ERROR 


HLR 


Error 


M 


The information element contains no application specific error 
values. 

The message is used also in the terminating network. 


START REPORTING 


HLR 






This message contains no information elements. 
The message is used also in the terminating network. 


START REPORTING 
ACK 


VLR 


Status 


M 


The information element contains subscriber status. It can take 
the following values: 

- CCBS Idle; 

- CCBS Not Idle; 

- CCBS Not Reachable. 

The message is used also in the terminating network. 


START REPORTING 
ERROR 


VLR 


Error 


M 


The information element contains no application specific error 
values. 

The message is used also in the terminating network. 


STOP REPORTING 


HLR 






This message contains no information elements. 
The message is used also in the terminating network. 


CCBS CALL 
REPORT 


VLR 


Mode 
Outcome 

Status 


M 
M 

C 


The information element indicates the reporting mode. It can 

take the following values : 

-A; 

-B. 

The information element indicates the outcome of the CCBS 

Call. It can take the following values: 

- Success; 

- Busy (only for mode A); 

- NDUB (only for mode B) 

- Failure. 

The information element contains subscriber status. It is set 
only for mode B. It can take the following values: 

- CCBS Idle; 

- CCBS Not Idle; 

- CCBS Not Reachable. 

The message is used also in the terminating network. 


CCBS CALL 
REPORT ACK 


HLR 






This message contains no information elements. 
The message is used also in the terminating network. 


CCBS CALL 
REPORT ERROR 


HLR 


Error 


M 


The information element contains no application specific error 
values. 

The message is used also in the terminating network. 


DEACTIVATE CCBS 


VLR 


CCBS Index 


C 


If CCBS Index is present the corresponding request shall be 
deleted, otherwise all requests shall be deleted. 


DEACTIVATE CCBS 
ACK 


HLR 


DeactivateResult 


M 


The information element can take the following values: 

- Success; 

- Not Provisioned. 


DEACTIVATE CCBS 
ERROR 


HLR 


Error 


M 


The information element contains no application specific error 
values. 
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Table 5.6.4.1 : Messages between VLR and HLR in the originating networl<, cont. 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


INTERROGATE 
CCBS 


VLR 


- 


- 


This message contains no information elements. 


INTERROGATE 
CCBS ACK 


HLR 


List(l-5)ofCCBS 
Description; 
No Entries; 

Not Provisioned 


C 

c 
c 


The list shall contain one entry for each CCBS Request for 
which the HLR stores data or; 
the queue is empty or; 

CCBS is not provisioned for the subscriber. 

Exactly one of these information elements shall be present. 
The structure of the CCBS Description is defined in 
table 5.6.1.3. 


INTERROGATE 
CCBS ERROR 


HLR 


Error 


M 


The information element contains no application specific error 
values. 



5.6.4.2 



Messages between VLR and HLR in the destination network 



These messages are used between VLR - HLR in the destination network. Some messages are used also in the 
originating network. They are marked accordingly. 

Table 5.6.4.2: Messages between VLR and HLR in the destination network 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


EVENT REPORT 


VLR 


- 


- 


Refer to table 5.6.4.1 


EVENT REPORT 
ACK 


HLR 


- 


- 


Referto table 5.6.4.1 


EVENT REPORT 
ERROR 


HLR 


- 


- 


Refer to table 5.6.4.1 


START REPORTING 


HLR 


- 


- 


Refer to table 5.6.4.1 


START REPORTING 
ACK 


VLR 


- 


- 


Refer to table 5.6.4.1 


START REPORTING 
ERROR 


VLR 


- 


- 


Refer to table 5.6.4.1 


STOP REPORTING 


HLR 


- 


- 


Refer to table 5.6.4.1 


CCBS CALL 
REPORT 


VLR 


- 


- 


Refer to table 5.6.4.1 


CCBS CALL 
REPORT ACK 


HLR 


- 


- 


Refer to table 5.6.4.1 


CCBS CALL 
REPORT ERROR 


HLR 


- 


- 


Refer to table 5.6.4.1 


PROVIDE ROAMING 
NUMBER 


HLR 


CCBS Call Reporting 
Request 


C 


Refer to GSM 03.18 

In addition: 

The information element shall be present for CCBS Call 

roaming number enquiry; otherwise it shall be absent. 
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5.6.5 Messages between MSC and HLR (C-interface) 

Table 5.6.5: Messages between MSC and HLR 



Message 


Message 
sender 


Information element 
name 


Information 
element 
Required 


Information element description 


SEND ROUTING 
INFO 


MSC 


CCBS Supported 
CCBS Call Indicator 


C 
C 


Refer to GSM 03.18 

In addition: 

The information element shall be present if GMSC supports 

CCBS; otherwise it shall be absent. 

The information element shall be present, if SRI is for CCBS 

Call; otherwise it shall be absent. 


SEND ROUTING 
INFO_ACK 


HLR 


CCBS Target 

Keep CCBS Call 
Indicator 


c 
c 


Refer to GSM 03.18 

In addition: 

The information element shall be present if the call is 

forwarded on busy and the subscriber B can be target of 

CCBS requests; otherwise it shall be absent. 

The information element shall be present if the VMSC 

supports CCBS and SRI enquiry was for CCBS Call; 

otherwise it shall be absent. 


SEND ROUTING 

INFO NEGATIVE 

RESPONSE 


HLR 


Negative Response 


- 


Refer to GSM 03.18 

New value(s) for existing parameter(s): 

- Busy_CCBS_Possible; 

- Busy_CCBS^Not_Possible. 



5.6.6 Messages between MSC - MSC (E-interface) 

Table 5.6.6: Messages between MSC and MSC 



Message 


Message 


Information element 


Information 


Information element description 




sender 


name 


element 
Required 




RESUME CALL 


MSC 


- 


- 


Refer to GSM 03.79 


HANDLING 








In addition: 






CCBS Target 


C 


The information element shall be present if the call is 
forwarded on busy and the subscriber B can be target of 
CCBS requests; otherwise it shall be absent. 



5.6.7 Existing parameters containing CCBS specific information 

Mobile Station Classmark 2 (refer to GSM 04.08 contains information whether "Network initiated MO CM connection 
request" is supported or not. This information is vital for the recall mechanism. 

CC capabilities (refer to GSM 04.08) contains information whether "Prolonged Clearing Procedures" are supported or 
not. This information is vital for the activation mechanism. 

SS-Code and SS-Status (refer to GSM 09.02) contains information whether CCBS service is provisioned to the 
subscriber. Both originating and destination CCBS service have their own SS-Code. 
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6 Monitoring and CCBS Call Reporting 

6.1 Monitoring 

6.1.1 Overview 

Monitoring is the process where the subscriber state is observed and reported. When monitoring is started, the current 
subscriber state is reported and any subsequent changes of subscriber state are reported until monitoring is stopped. 

Monitoring subscriber state information will be necessary against MS B and may also be necessary against MS A. 

For both these cases the monitoring functionality is located in the appropriate serving VMSC/VLR and is controlled 
from the appropriate HLR. The actions on the A-side and B-side for monitoring are completely independent and the 
following description is generic to cover either case. The HLR sends an explicit Start Reporting signal to the VLR to 
initiate monitoring. The VLR acknowledges the request confirming that monitoring has started and indicates the current 
status of the subscriber state in the VMSC/VLR. The VLR will continue to send an Event Report to the HLR whenever 
the appropriate subscriber state transition event occurs. The HLR sends an explicit Stop Reporting signal to the VLR 
when reporting on the subscriber state transitions is no longer required. 

6.1 .2 Monitoring Subscriber B-state information 

The CCBS service requires monitoring of the subscriber state at the called destination network (B-side). This monitoring 
enables the HLR B to be aware of any transition of subscriber state in VMSC/VLR B while there is an active CCBS 
Request in the HLR B queue. The basic service operation is that, when the destination B subscriber state becomes Idle, 
the HLR B is informed and a Remote User Free indication is sent towards the originating A network at the appropriate 
time. If subsequently to that event the destination B subscriber state becomes not Idle or not reachable, then the HLR B 
is informed by the VMSC/VLR B in order that it can take an appropriate action towards HLR A, e.g. defer sending of 
the Remote User Free indication. 

6.1 .3 Monitoring Subscriber A state information: 

Monitoring Subscriber A state information will be necessary if the Remote User Free indication from Destination B 
network cannot be acted upon because e.g. MS A is not idle or not reachable and leads to the CCBS request being 
suspended. The service action in this event is that, when the subscriber state subsequently becomes Idle, the HLR A is 
informed and a Resume indication is sent towards the destination B network at the appropriate time. 
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6.2 MSC/VLR Monitoring IVIodel 



The Monitoring model represents the information related to the status of the subscriber connection in the MSC/VLR. A 
generic monitoring model is used in the MSC/VLR covering the needs of both subscriber A and subscriber B state 
information for CCBS. The MSC/VLR monitoring model for CCBS is shown in figure 6.2. Note that state transitions 
reported to the HLR are shown as solid lines. 



NOT 
REACHABLE 




Figure 6.2: MSC/VLR Monitoring Model 

6.2.1 Subscriber Status 

The monitoring model in the MSC/VLR makes use of the three subscriber states described in table 6.2.1. 
NOTE: Refer to GSM 03.78 for equivalent subscriber state description. 

Table 6.2.1 : Subscriber States 



Subscriber states 


Description (for monitoring purposes) 


Notes 


IDLE 


The state of the MS is neither "NOT IDLE" nor "NOT 
REACHABLE" 


"Assumed Idle" 


NOT IDLE 


The MS is engaged on a transaction for a MO or MT 
circuit switched call 


"CAMEL busy" 


NOT REACHABLE 


The MSC/VLR can determine from its internal data that 
the MS is not reachable e.g. IMSI detached, Restricted 
Area, No Page Response. 


"Network Determined 
Not Reachable" 



For each subscriber state a description can be found on the entry events, functions and exit events. 
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6.2.1.1 Idle 

Entry events: 

Indication of last call released (Mobile Originated or Mobile Terminated); 
Indication of radio link failure; 

- Indication of MS activity related to e.g. MO-SMS, MT-SMS and CISS; 

- IMSI Attached; 

- Location Update. 
Functions: 

Events leading to a transition to the Not Idle or Not Reachable subscriber state are awaited. 
Exit events: 

A Mobile Originated Set-up message is received from the MS for first (and only) call; 
A Mobile Terminated Set-up message is sent to the MS for first (and only) call. 

- IMSI Detached; 
Roaming in LA not allowed; 

- No Page Response; 

An exception condition is encountered e.g. Cancel Location indication received. 

6.2.1.2 Not Idle 

Entry events: 

A Mobile Originated Set-up message is received from the MS for first (and only) call; 

A Mobile Terminated Set-up message is sent to the MS for first (and only) call. 
Functions: 

Events leading to a transition to the Idle or Not Reachable subscriber state are awaited. 
Exit events: 

Indication of last call released (Mobile Originated or Mobile Terminated); 

Indication of radio link failure; 

An exception condition is encountered e.g. Cancel Location indication received. 

6.2.1.3 Not Reachable 

Entry events: 

- IMSI Detached; 
Roaming in LA not allowed; 
No Page Response. 

Functions: 

Events leading to a transition to the Idle or Not Idle subscriber state are awaited. 
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Exit events: 

- Indication of MS activity related to e.g. MO-SMS, MT-SMS and CISS; 

- IMSI Attached; 

- Location Update; 

A Mobile Originated Set-up message is received from the MS for first (and only) call; 
A Mobile Terminated Set-up message is sent to the MS for first (and only) call; 
An exception condition is encountered e.g. Cancel Location indication received. 

6.2.2 Reporting of subscriber state transitions 

Transitions between subscriber states are reported from the MSCA'LR, while monitoring in the MSCA'^LR is on going. 
The table 6.2.2 indicates which transitions are monitored in the MSC/VLR and whether these are reported to the HLR 
for the CCBS service. An appropriate Event Report signal is sent from the VLR to the HLR when a relevant state 
transition occurs. The Event Report signal includes a status parameter which reflects the subscriber state information. 

Table 6.2.2: Reporting of Subscriber States Transitions 



Subscriber state transition event 


Event reporting 
HLR informed 


Event report 
Subscriber status 


IDLE to NOT IDLE 


Yes 


CCBS Not Idle 


IDLE to NOT REACHABLE 


Yes 


CCBS Not Reachable 


NOT IDLE to IDLE 


Yes 


CCBS Idle 


NOT IDLE to NOT REACHABLE 


No 


- 


NOT REACHABLE to IDLE 


Yes 


CCBS Idle 


NOT REACHABLE to NOT IDLE 


No 


- 



6.2.2.1 



Start Reporting of Monitoring Events 



When a Start Reporting signal is received from the HLR, the VLR shall acknowledge the request confirming that 
monitoring has started and indicate the current status of the subscriber state in the MSCA'^LR. The VLR shall 
subsequently continue to send the Event Reports indicated in table 6.2.2 whenever the appropriate subscriber state 
transition event occurs. 

Note where a single user has a CCBS request activated against him and has an outstanding CCBS request suspended 
against someone else, (i.e. is effectively both destination B and CCBS subscriber A) reporting on both A-side and B-side 
is required. In this case, the VLR shall only send a single Event Report as indicated in table 6.2.2 whenever the 
appropriate subscriber state transition event occurs. The HLR shall not send another Start Reporting signal to the VLR if 
monitoring is already ongoing in the MSC/VLR for either A-side or the B-side. 



6.2.2.2 Stop Reporting of Monitoring Events 

When a Stop Reporting signal is received from the HLR, the VLR shall stop sending the Event Reports. 
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6.3 CCBS Call Reporting 
6.3.1 Overview 

As well as monitoring of the subscriber state, it is also necessary to report the result of the CCBS Call. The basic 
reporting requirements are as follows from both the A-side and the B-side. 

CCBS Call Reporting - A-side: 

The CCBS service logic in the originating network HLR A requires a report on the outcome of the CCBS Call resulting 
from the acceptance of the CCBS Recall by Subscriber A. The VLR A sends a CCBS Call Report to the HLR A 
indicating the outcome of the CCBS call processing in MSC/VLR A when e.g. an address complete message (ACM) is 
received from the destination B network. CCBS Call Reporting on the A-side is completely independent of any 
monitoring of subscriber state information. The sending of CCBS Call Report is required even when there is no 
monitoring ongoing in the MSC/VLR. 

CCBS Call Reporting- B-side: 

The CCBS service logic in the destination network HLR B requires a report on the outcome of CCBS Call processing in 
the MSC/VLR B. The HLR B initiates the CCBS call outcome reporting in the VLR when the VLR is normally queried 
to provide routing information for mobile terminated calls (by including an CCBS indicator in the PRN message). The 
VLR B sends a CCBS Call Report to the HLR B indicating the outcome of the CCBS call processing and the new status 
of the subscriber state in the MSC/VLR B when e.g. MS B is alerted to the CCBS Call. 



6.3.2 Originating Network (A-side) 



When a CCBS RUF signal is received by the VLR, CCBS processing in the MSC/VLR leads to a CCBS Recall signal 
being sent to the MS. When the response to the CCBS Recall is received, the VLR shall subsequently send a CCBS Call 
Report when the relevant processing for the outgoing CCBS call to the destination network is completed as shown in the 
SDLs for MSC/VLR A. 

6.3.3 Destination Network (B-side) 

When an initiate CCBS Call Reporting Request signal (B-side) is received by the VLR in the Provide Roaming Number 
message, the VLR shall subsequently send a CCBS Call Report when the relevant processing of the incoming CCBS call 
is completed as shown in the SDLs for MSC/VLR B. 

6.3.3.1 Interaction of Event Reporting and CCBS Call Report 

Reporting on subscriber state transitions will be ongoing in the MSC/VLR B when a report on the CCBS call outcome is 
required. 

When a subscriber state transition from IDLE to NOT IDLE occurs due to an incoming CCBS call, an Event Report 
shall not be sent. Instead, a CCBS Call Report (containing CCBS call outcome information and the status) shall be sent 
to the HLR B. After the CCBS Call Report has been sent, normal Event Reporting will continue i.e. the VLR shall 
subsequently send only the Event Reports indicated in table 6.2.2 when the next appropriate subscriber state transition 
event occurs. 



6.4 Location Update 



The MS may roam to a new MSC/VLR area while monitoring is ongoing in the previous MSC/VLR. When the VLR 
receives a Cancel Location signal from the HLR due to normal mobility management procedures, any ongoing CCBS 
related activities associated with the subscriber shall cease. 

If the A-side monitoring is ongoing when the HLR receives a Location Update request from the new VLR, the Location 
Update signal is considered to indicate that the subscriber state is idle and the appropriate CCBS process in the HLR is 
informed. The normal mobility management procedures will lead to a Cancel Location signal being sent to the old VLR 
causing the Event Reporting to stop. 
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If the B-side monitoring is ongoing when the HLR receives a Location Update request from the new VLR, the normal 
mobility management procedures are followed. On successful completion of Location Update procedure, the HLR shall 
send a Start Reporting signal to the new VLR. If during the handling of the normal Location Updating procedure, it is 
detected that the new MSC/VLR does not support CCBS, the HLR shall not send a Start Reporting signal to the new 
VLR. 

NOTE: There is no impact to the MS due to CCBS monitoring, i.e. normal Location Update procedures apply. 



7. Mobility 

The handling for CCBS specific mobility is described below. 

7.1 Mobility during Activation 

In order to allow the activation of CCBS when the call is released, the CC connection towards the MS shall be kept, to 
avoid any problems of mobility with the MS A. 

Therefore the MSC shall maintain the CC connection with the MS A while Tl is running and until either Tl expires or 
the MSC sends a CCBS REQUEST ACK or CCBS REQUEST ERROR to the MS. After MSC has sent CCBS 
REQUEST ACK or CCBS REQUEST ERROR, the MSC A shall release the CC connection with MS. 

7.2 Number used within CCBS Call 

The activating MSC A shall store the originally dialled number in the Call Information container. The TranslatedBNo 
parameter shall contain destination B address stored in international E.164 format. 

If the MS A is registered outside of the HPLMN during the initial call or when Remote_User_Free is received from the 
destination B network the HLR A may request the recall MSC A to change the number used for CCBS Call to the 
TranslatedBNo instead. Refer to the SDLs for originating MSCA^LR. 

If CAMEL service was activated in the original call the HLR A shall not request to change the number used for the 
CCBS Call. 



7.3 MS does Location Update 



CCBS does place extra requirements for the Location Update procedure in the HLR when MS is monitored. Refer to 

subclause 6.4. 

7.4 Mobility during CCBS Call in the destination network 

If MS registers to non-supporting network special handling has to be applied. Refer to subclause 10.1.3. 
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8 Interaction with other supplementary services 

GSM 02.93 specifies a number of interactions between CCBS and other supplementary services. Additional details of 
how these interactions apply are as follows. 

8.1 Call forwarding unconditional (CFU) 

If a call to destination B is forwarded to subscriber C by CFU and MS C is NDUB, the GMSC shall inform MSC A that 
CCBS is not possible when it releases the call. Refer to Process MT_GMSC (see GSM 03.18) for further details. 

If destination B activates CFU after subscriber A has activated a CCBS Request against destination B, HLR B shall not 
process CCBS Requests in the queue which are related to the relevant Basic Service Group, except that T7 shall 
continue for each CCBS Request in the destination B queue. If T7 expires for a particular request, HLR B shall cancel 
the request, as described in the SDLs shown in figure 10.13. 

If MSC B is monitoring MS B when CFU is activated by destination B and all the CCBS Requests in the destination B 
queue subsequently become "Active and Quiescent", then HLR B shall send "Stop Reporting" to MSC B. If destination 
B deactivates CFU resulting in one or more requests becoming "Active and Operative" in the destination B queue then, 
HLR B shall send "Start Reporting" to MSC B if monitoring is not already ongoing. 

A CCBS Call shall be forwarded without the CCBS call Indicator. 



8.2 Call forward on busy (CFB) 



If a call to destination B is forwarded to subscriber C by CFB and MS C is NDUB, the forwarding switch (GMSC or 
VMSC) shall inform MSC A that CCBS is possible when it releases the call. Refer to Process MT_GMSC or Process 
ICH_MSC (see GSM 03.18) for further details. 

If destination B activates CFB after subscriber A has activated a CCBS Request against destination B, HLR B shall 
continue to process CCBS Requests in the queue. If a CCBS Call subsequently arrives at MSC B and MS B is NDUB, a 
network provider option exists as to whether: 

- the CCBS call shall be treated as when MS B is busy for the CCBS call, without CFB active; or 

- the CCBS call shall be forwarded without the CCBS call Indicator. 

8.3 Call forwarding on no reply (CFNRy) 

If a call to destination B is forwarded to subscriber C by CFNRy and MS C is NDUB, the forwarding switch (VMSC) 
shall inform MSC A that CCBS is not possible when it releases the call. Refer to Process MT_GMSC or Process 
ICH_MSC (see GSM 03.18) for further details 

If destination B activates CFNRy after subscriber A has activated a CCBS Request against destination B, HLR B shall 
continue to process CCBS Requests in the queue. 

A CCBS call shall be forwarded without the CCBS call Indicator. 

8.4 Call forwarding on MS not reachable (CFNRc) 

If a call to destination B is forwarded to subscriber C by CFNRc and MS C is NDUB, the forwarding switch (GMSC or 
VMSC) shall inform MSC A that CCBS is not possible when it releases the call. Refer to Process MT_GMSC or 
Process_ICH_MSC (see GSM 03.18) for further details. 

If destination B activates CFNRc after subscriber A has activated a CCBS Request against destination B, HLR B shall 
continue to process CCBS Requests in the queue. 

The CCBS call shall be forwarded without the CCBS call Indicator. 
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8.5 Call Waiting (CW) 

No impact. 

8.6 IVIultiparty service (IVIPTY) 

No impact. 

8.7 Closed user group (CUG) 

No impact. 

8.8 Advice Of Charge (AoC) 

If subscriber A accepts a "CCBS Recall" indication but ACMmax exceeds, then MSC A shall cancel the associated 
request and shall not establish the CCBS Call. 

8.9 Barring of all outgoing calls (BAOC) 

If subscriber A accepts a "CCBS Recall" indication but MSC A detects that BAOC is active and operative, then MSC A 
shall cancel the associated request and shall not establish the CCBS Call. 

8.10 Barring of outgoing international calls (BOIC) 

If subscriber A accepts a "CCBS Recall" indication but the CCBS Call would be an international call and MSC A 
detects that BOIC is active and operative, then MSC A shall cancel the associated request and shall not establish the 
CCBS Call. 

8.1 1 Barring of outgoing international calls except those directed 
to the home PLIVIN country (BOIC-exHC) 

If subscriber A accepts a "CCBS Recall" indication but the CCBS Call would be an international call except to the home 
PLMN country and MSC A detects that BOIC-exHC is active and operative, then MSC A shall cancel the associated 
request and shall not establish the CCBS Call. 

8.12 Barring of all incoming calls (BAIC) 

If a CCBS Request arrives at HLR B and HLR B detects that BAIC is active and operative for the relevant Basic Service 
Group, then HLR B shall not accept the activation attempt and shall indicate short term denial in the response. 

If MSC B is monitoring MS B when BAIC is activated by destination B then all the CCBS Requests in the destination B 
queue subsequently become "Active and Quiescent" and HLR B shall send "Stop Reporting" to MSC B. If destination B 
deactivates BAIC resulting in one or more requests becoming "Active and Operative" in the destination B queue then, 
HLR B shall send "Start Reporting" to MSC B if monitoring is not already ongoing. 

If barring of all incoming calls becomes active and operative for a particular Basic Service Group for destination B, such 
that a CCBS call from subscriber A is not permitted, HLR B shall cancel the associated request related to the Basic 
Service Group and select the next non-suspended request in the queue for processing for other Basic Service Groups. 
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8.13 Barring of incoming calls when roaming outside the home 
PLIVIN country (BIC-Roam) 

If a CCBS Request arrives at HLR B and HLR B detects that BIC-Roam is active and operative for the relevant Basic 
Service Group, then HLR B shall not accept the activation attempt and shall indicate short term denial in the response. 

If MSC B is monitoring MS B when BIC-Roam is activated by destination B then all the CCBS Requests in the 
destination B queue subsequently become "Active and Quiescent" and HLR B shall send "Stop Reporting" to MSC B. If 
destination B deactivates BIC-Roam resulting in one or more requests becoming "Active and Operative" in the 
destination B queue then, HLR B shall send "Start Reporting" to MSC B if monitoring is not already ongoing. 

If barring of incoming calls when roaming outside the home PLMN country becomes active and operative for a 
particular Basic Service Group for destination B, such that a CCBS call from subscriber A is not permitted, HLR B shall 
cancel the associated request related to the Basic Service Group and select the next non-suspended request in the queue 
for processing for other Basic Service Groups. 

8.1 4 Completion of calls to busy subscriber (CCBS) 

Subscriber A may have successfully activated one or more CCBS requests against different destinations B, and also have 
one or more CCBS requests successfully activated against him by different subscribers. In this case, HLR A shall co- 
ordinate the different requests. 

Checking for an identical CCBS request already existing shall include checks in both directions, i.e. if subscriber A 
activates a CCBS Request against destination B, HLR A shall check subscriber A's originating queue for any previous 
requests activated by subscriber A against destination B for the same basic service group. HLR A shall also check 
subscriber A's target queue for any requests activated by destination B against subscriber A for the same basic service 
group. 
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9 Interaction with other network features 

GSM 02.93 specifies a number of interactions between CCBS and other network features. 

9.1 Customised Applications for Mobile network Enhanced 
Logic (CAIVIEL) 

For a terminating CAMEL based service which changes the destination B address for the original call which 
subsequently encounters NDUB, the GMSC shall inform originating network that CCBS is not possible when it releases 
the call. 

If an originating CAMEL based service determines for a CCBS Call a different destination B Address than for the 
original call, the CCBS Call shall be released and the associated CCBS Request shall be cancelled. 

If the CAMEL based service requests a call set-up to an alternative destination after the original call has met Busy, 
CCBS Possible condition, the CCBS activation shall be allowed if the alternative call set-up also encounters Busy 
condition. 

9.2 Support of Optimal Routeing (SOR) 

The CCBS supporting GMSC shall include CCBS Supported indicator to the SRI message. 

If HLR B receives a request for routeing information when destination B is blocked (i.e. the HLR B is waiting for an 
SRI for a CCBS call set-up) and the SRI does not include a CCBS call indicator nor CCBS supported in the GMSC 
indicator and the request is from a GMSC not in the same PLMN as HLR B, then HLR B shall return an SRI negative 
response indicating OR not allowed. This will force the GMSC to route the call to a GMSC in the same PLMN as 
HLR B (see GSM 03.79). 

The GMSC in HPLMN B should be able to include the CCBS Call indicator in the non-OR SRI, and the CCBS call set- 
up will proceed, although it won't be optimally routed. 

If the HLR receives an SRI indicating a CCBS-capable GMSC but not a CCBS call while awaiting SRI for a CCBS call, 
it can treat the request as if the B-subscriber were busy, regardless of where the GMSC is. 
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10 Interworking with other networks 

The point of interworking shall be the interface between HLR A and HLR B. The flow of information across this 
interface shall be identical to that between exchanges for the ISDN version of CCBS. 

Interworking with ISDNs which support the ISDN version of CCBS is therefore available without further modification. 

Interworking with networks other than ISDNs, e.g. private networks, is not specified here, but is not precluded. 

CCBS shall be able to interwork through networks which do not support CCBS. In this situation, the CCBS service may 
fail. 

1 0.1 Interworking with network entities not supporting CCBS 

CCBS requires support of the service by the following entities for it to operate as specified above: 

- MSA; 

- MSC A; 

- VLRA 

- HLR A 

- GMSC 

- HLRB 

- MSCB 

- VLR B. 

The following shows the actions required to cover the situations where these entities do not support CCBS. Note that the 
situation is further complicated by mobility. For example, MSC A may support CCBS when the initial request is made, 
but if subscriber A has changed location, the new MSC A may not support CCBS. 

It is assumed that the entities support the service at the points in the call where actions are initiated by them, and that an 
entity which receives an indication for the CCBS service but does not support it can indicate its lack of support to the 
sending entity. 

10.1.1 CCBS not supported by MSC A 

HLR A knows whether the MSC A supports CCBS or not through the transfer of subscriber data. 

MS B becomes idle 

When HLR A receives the "Remote User Free" indication for a particular CCBS Request and detects that the MSC A 
where MS A is currently registered does not support CCBS, then HLR A shall suspend the corresponding CCBS 
Request and shall send "CCBS Suspend" to HLR B. When MS A registers in a different MSC which supports CCBS, 
HLR A shall resume the corresponding CCBS Request and shall send "CCBS Resume" to HLR B, continuing as if 
MS A had become free. 

10.1.2 CCBS not supported by HLR B 

Initial call encounters busy 

If an MSC B that supports CCBS recognises that HLR B does not support CCBS then "CCBS Not Possible" will be 
generated in the CCBS diagnostic. 
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10.1.3 CCBS not supported by MSC B 

HLR B knows whether the MSC B supports CCBS or not through the transfer of subscriber data. 

CCBS Request 

If MSC B does not support CCBS, HLR B acknowledge the request and start T7. No processing of the destination B 
queue and subsequently no monitoring of destination B will be possible until destination B registers in a supporting 
MSC. 

CCBS Call set-up 

If HLR B knows that MSC B does not support CCBS the HLR B shall delete the corresponding CCBS Request and shall 
request a Roaming No without including the CCBS Call indicator in the request. Within Send Routeing Info Ack the 
HLR shall inform the GMSC to remove CCBS Call Indicator from the lAM message. 

After a "Remote User Free" has been sent from MSC B but before the CCBS call set-up is completed, destination B may 
register in an MSC which does not support the service. MSC B shall accept the CCBS call, but MSC B will not be able 
to inform HLR B of the successful completion of the CCBS call, so the request will remain active in HLR B until the 
recall B timer (T9) expires and the request is cancelled. 



GSM 03.93 version 6.1 .0 Release 1 997 38 TS 1 01 283 V6.1 .0 (1 998-07) 



1 1 Network entity functions 



The following SDL diagrams describe the various processes and procedures within individual network entities for 
handling CCBS. The SDL diagrams are as follows: 

11.1 Originating Network Processes 
11.1.1 Processes and procedures in MSC/VLR 

Figure U.l: Process MSC_CCBS_Recall_Manager 

This process controls the CCBS Recall handling in the MSC and controls timers T4 and TIO 

Figure n.2: Process VLR_CCBS_Recall_Manager 

This process controls the CCBS Recall handling in the VLR and reports the result of the Recall directly to the HLR. 

Figure n.3: Process OCH_CCBS_VLR 

This process controls the CCBS Call Setup in the VLR 

Figure II A: Procedure CCBS_Check_OG_Call 

This procedure checks whether the outgoing call meets various conditions set by the CCBS supplementary service. If 
CCBS is not implemented Pass exit shall be taken. 

Figure U.S: Procedure CCBS_Check_If_CCBS_Possible 

This procedure is called when Release message is received from the destination network. It checks whether CCBS 
activation is possible. 

Figure 1L6: Procedure CCBS_Activation_MSC 

If CCBS activation is possible this procedure is called. It handles the dialogue between MS and MSC and MSC and 
HLR respectively. 

Figure U.?: Procedure Page_MS_MSC_For_Recall 

During CCBS recall this procedure handles paging of the MS if the location area id is known. 

Figure U.8: Procedure Search_For_MS_MSC_For_Recall 

During CCBS recall this procedure handles paging of the MS on MSC side if the location area id is not known. 

Figure n.9: Procedure Search_For_MS_VLR_Recall 

During CCBS recall this procedure handles paging of the MS on VLR side if the location area id is not known. 

Figure ILIO: Procedure Complete_Recall_MSC 

During CCBS recall this procedure handles early channel allocation and establish CC connection with the MS. 

Figure U.ll: Procedure CCBS_OCH_Report_Success 

This procedure is called when CCBS call is successfully delivered to the destination network. The procedure informs 
HLR of successful call delivery. 

Figure U.l 2: Procedure CCBS_OCH_Report_Failure 

This procedure is called when CCBS call delivery failed to the destination network. The procedure informs HLR of call 
delivery failure. 
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Process MSC_CCBS_Recall_Manager 
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Figure 1 1 .1 : Process l\flSC_CCBS_Recall_l\flanager (sheet 1 of 4) 
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Process MSC_CCBS_Recall_Manager 
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Figure 1 1 .1 : Process l\/ISC_CCBS_Recall_IUIanager (sheet 2 of 4) 
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Process MSC_CCBS_Recall_Manager 
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Figure 1 1 .1 : Process l\/ISC_CCBS_Recall_IUIanager (sheet 3 of 4) 
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Process MSC_CCBS_RecalLManager 
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Figure 1 1 .1 : Process MSC_CCBS_Recall_Manager (sheet 4 of 4) 
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Process VLR_CCBS_Recall_Manager 
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Figure 11.2: Process VLR_CCBS_Recall_Manager (sheet 1 of 4) 
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Process VLR_CCBS_Recall_Manager 
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11 .1 .2 Processes and procedures in HLR 

Figure 11.13: Block diagram of HLRA processes 

Figure 11.14: Process HLRA_Request_Manager 

This process is in charge of the user interface procedures and queue handling, i.e. whether the request to processed is 
present in the queue or not. 

The process has three states, "Idle", "Operative" and "Operative Resuming". In the "Idle" state the queue is empty and 
the only actions to queue are creation of new request and interrogation of the queue. In other states activation, 
interrogation and deactivation procedures similarly, that is why they are grouped under "*" state. 

Whenever the first request is created the process changes it's state to "Operative", in this state there are request(s) in the 
queue and none of them are suspended. 

When HLRA_Request reports of suspension the process changes it's state to "Operative Resuming" and the 
HLRA_Resume is started with correct trigger signal i.e. idle indication from MSC or recall end is waited. 

Only NET suspended request can be selected and resumed, USER type suspended requests remain as suspended until 
them are marked as NET suspended. This happens when idle indication is received from the MSC. 

The resuming process is paused if there is new suspended request with cause code Not reach i.e. The resuming starts 
again when idle condition is met again or there is a new recall with successful outcome i.e. the recall ends without Not 
Reach indication. 

The resuming process will be stopped, if there are no suspended requests in the queue any more. The process changes 
it's state to normal "Operative" or "Idle" state. 

Figure 11.15: Process HLRA_Request 

This process is created during the activation of service and contains all related data. The process has five different states, 
"Wait_For_Answer", "Active", "Recall", "Suspended" and "Frozen". During its creation the process sends 
CCBS_Request via SSAP interface to destination network B containing all call related data as well originating networks 
retention capabilities. 

In the "Wait_For_Answer" state process receives response from destination network which is further relayed to the 
HLRA_Request_Manager. In case of positive acknowledgement destination network returns info whether the retention 
is supported in both networks. 

In "Active" state process waits recall from destination network, however process can vanish if operation timer T3 
expires or explicit deletion is received from the user or destination network. In case of deletion the process informs the 
queue. When the recall arrives the process transits to the "Recall" state. 

In the "Recall" state process waits the recall outcome, either positive or negative. Depending of the recall outcome the 
request can be deleted, retained or suspended. If the request is to be retained the process transits back to the "Active" 
state. If the request is suspended due to the TIO expiry, CCBS_Busy condition or the MS is not reachable the process 
transits to the suspended state. 

If the request is deleted during "Recall" due SSAP_Cancel, T3 expiry or explicit deletion the queue is updated 
immediately and the request changes it's state to "Recall Deleted" where it waits the recall to end. 

In the "Suspended" state actions the request can be resumed if the MS is known to be CCBS_Idle or the request can be 
deleted due to the explicit deletion or timer T3 expiry. 

The request is placed in "Frozen" state whenever it receives Remote User Free indication from the destination network 
and the request can't be fulfilled due service interaction or lack of support in MSCVLR. The request shall indicate 
suspended back to the destination network and stay in the queue. If the service becomes later possible, the request will 
revert back "Active" state and indicate resumed to the destination network. 

Figure 11.16: Process HLRA_Recall_Manager 

This process has two different states, "Idle" and "CCBS_Busy". 
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The process let's only one individual process to be in recall state in a time and have a dialogue open to the MSC and it 
changes it's state to "CCBS_Busy". In this state other requests are suspended immediately and marked as NET 
suspended with cause code = Busy. 

In "CCBS_Busy" state the process waits recall reporting from the MSC. Possible inputs from the MSC are 
CCBS_RUF_Ack, CCBS_RUF_Error and CCBS_Call_Report. CCBS_Call_Report can be received if the subscriber 
has accepted the recall, otherwise the process changes it's state back to "Idle". If the process receives Query_State 
request from the HLRA_Resume during the recall the process informs the resume process whether a recall is being 
processed. 

Figure 11.17: Process HLRA_Resume 

The process has four different states, "Idle", "Resume pending", "Wait For Selection" and "Resuming". The process is 
started when a request is suspended. For the first suspended request it is also set the trigger point i.e. when it is correct to 
send out selection request for resuming. Two triggers are provided, A_Idle from the monitoring process and Recall_End 
from the recall handling. If the trigger is set to A_Idle the monitoring process is also started. 

When the process is started and correct trigger is set the process waits in the "Resume pending" state to receive a 
permission to start resuming. When the permission is received the process asks for the first NET request to resumed. If 
A_Idle signal is received from the monitoring process the resuming process asks the queue manager to set all suspended 
requests as NET type in order to allow the selection. 

When there are no active suspended request in the queue any more the resuming process is stopped i.e. when the 
"Deleted" signal in the HLRA_Request_Manager is handled. 

Figure 11.18: Process HLRA_Monitoring 

Monitoring process has two different states, "Idle" and "Monitoring". Receival of "A_Query" signal transits the process 
to "Monitoring" state. In this state the process reports "Idle" condition to the resuming process and starts the monitoring 
again in the MSC if location update or restore data happens. 

Figure 11.19: Procedure HLRA_CCBS_Check_Interactions 

This procedure checks whether the Remote User Free indication can be delivered to the MSCVLR or not. 
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Figure 11.13: HLRA Processes 



NOTE: Figure 11.13 is one possible method of implementing queue processing in HLR A. Manufacturers are not 
constrained to follow the implementation given in figure 11.13. However, the external behaviour of 
HLR A shall appear to be the same. 

Description of above signals: 

Relation HLRA_Request_Manager and HLRA_Request 

CCBS Request Ack signal is acknowledgement of a successful activation from the individual request to the queue 
manager. 
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CCBS Request Error signal is sent if the destination networks queue is full or the destination networks queue size is set 
to zero. The individual request is deleted from the originating side. 

Suspend is used within HLRA_Request and HLRA_Request_Manager. The queue shall update it's internal information. 

Delete is used within HLRA_Request_Manager and HLRA_Request. The queue manager instructs the individual 
request the request to die. 

Deleted is used within HLRA_Request_Manager and HLRA_Request. The individual request informs the queue of its 
expiry. 

Resume is used within HLRA_Request_Manager and HLRA_Request. The individual request is resumed and it shall 
inform the destination network of the resumption. 

Relation HLRA_Request_Manager and HLRA_Resume 

Set Trigger Recall End is used within the HLRA_Request_Manager and HLRA_Resume. If resuming is not ongoing 
this signal set the resuming process to the "ResumePending" state and query is sent to the recall process. 

Set Trigger A Idle is used within the HLRA_request_manager and HLRA_resume. If resuming is not ongoing this 
signal set the resuming process to the "ResumePending" state. In all cases this causes "A_Query" signal to be sent. 

Reset Trigger A Idle is used within the HLRA_request_manager and HLRA_resume. This signal sets the resuming 
process to the "ResumePending" state and causes "A_Query" signal to be sent. 

Select Resp is used within the HLRA_request_manager and HLRA_resume. This signal informs the resuming process 
to start TU. 

Not Selected is used within the HLRA_request_manager and HLRA_resume. This signal informs the resuming process 
that the selection was not done and the process will transit to "ResumePending" state. 

Stop Resume is used within the HLRA_request_manager and HLRA_resume. This signal informs the resuming process 
to stop it's actions and stop the monitoring also. 

Set All Active is used within the HLRA_Resume and HLRA_request_manager. This signal informs the queue to set all 
suspended requests as NET suspended and later on they can be resumed. 

Select Active Req is used within the HLRA_Resume and HLRA_request_manager. This signal informs the queue to 
select first NET suspended request to be resumed. If successful the request process will return "Select_Resp", otherwise 
"Not_Selected". 

Select First Req is used within the HLRA_Resume and HLRA_request_manager. This signal informs the queue to 
select first suspended request to be resumed. If successful the request process will return "Select_Resp", otherwise 
"Not_Selected". 

Relation HLRA_Recall_Manager and HLRA_Request 

Recall is used within HLRA_Request and HLRA_Recall_Manager. It contains all call related data in order to form the 
CCBS_Call. 

Completed is used within the HLRA_Recall_Manager and HLRA_Request. It informs the request of successful 
CCBS_Call and causes the request to vanish. 

Failure is used within the HLRA_Recall_Manager and HLRA_Request. It informs the request of unsuccessful 
CCBS_Call and causes the request to vanish. 

Busy is used within the HLRA_Recall_Manager and HLRA_Request. It informs the request of unsuccessful CCBS_Call 
and causes the request to vanish if retention is not supported. 

Suspend is used within HLRA_ Recall_Manager and HLRA_ Request. The request shall change it's state and report the 
suspension to the queue manager. 

Relation HLRA_Monitoring and HLRA_Resume 
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A Query is used within HLRA_Resume and HLRA_Monitoring. It instruct the HLRA_Monitoring to start it's actions 
and return the idle condition when possible. 

A Idle is used within HLRA_Monitoring and HLRA_Resume. It informs the resuming process that the subscriber is 
now CCBS_Idle and not CCBS_Busy. 

Stop Monitoring is used with HLRA_Resume and HLRA_Monitoring. It instructs the monitoring process to stop it's 
actions and stop the monitoring from VLR also. 

Location Update/Restore Data events are tracked and external reporting is started again. 
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Figure 11.14: Process HLRA_Request_l\flanager (sheet 1 of 10) 
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Figure 11.14: Process HLRA_Request_l\flanager (sheet 2 of 10) 
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Figure 11.14: Process HLRA_Request_IUIanager (sheet 3 of 10) 
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GSM 03.93 version 6.1.0 Release 1997 



86 



TS101 283 V6.1. 0(1998-07) 



Process HLRA Resume 



SelecL 
Resp 



Start T11 



RESUMING 



Rom HLRA_ 
Request_Manager 



From HLRA_ ' Not_ 
Request_Manager' Selected 



RESUME_ 
PENDING 



WAIT_FOR_ 
SELECTION 



FromHLRA_ 
Monitoring 



RESUMING 



ToHLRA_ 
Request_Manager 



T1 1 expiry 



Select_ 
Actlve_ 
Req 



WAIT_FOR_ 
SELECTION 



FromHLRA_ 
Monitoring 



>A Idle 



To HLRA_ ' Set_AII_ 

Request_Manager' Actwe 



A Idle 



3(3) 



From HLRA_ 
Recall_Manager 



Recall 



/ / 



From HLRA_ 
Recall_Manager 



> Recall 



Stop T1 1 



RESUME 
PENDING 



Figure 11.17: Process HLRAResume (sheet 3 of 3) 



GSM 03.93 version 6.1.0 Release 1997 



87 



TS101 283 V6.1. 0(1998-07) 



Process HLRA_Monitoring(1,1 ) 



1(2) 



MX 

IDLE 



IDLE 



A_Query , 
{Sus_Cau9e) 



Signals to/ from left are to/ from 

(XBS_Coordinator_HLR unless 

shown otheiwise. 

Signals to/ fromright are to/from 

HLRAResume uless shown 

otherwee 



*(IDL£) 



K 



Start_ 
Fteportiig 



\z 

WAIT_FOR_ 
ANSWER 



WAIT_FOR_ 
ANSWER 



Event_ 

> Report 

(Status) 



Stop_ 
Monitoring 



Stop_ 
Reporting 




Yes 



NOTE: Using the previous history 
data i.e. Sus_Cause value to prevent 
any unnecessary signaing is one 
possible implementation. The 
manufacturer is allowed to use other 
techncs to achieve effcient solution. 




Yes 



ELSE 



A Idle 






MONITORING 



Figure 11.18: Process HLRA Monitoring (sheet 1 of 2) 



GSM 03.93 version 6.1.0 Release 1997 



88 



TS101 283 V6.1. 0(1998-07) 



Process HLRA_Monitoring(1,1 ) 



2(2) 



MONITORING 



Signals to/ from left are to/ from 

(XBS_Coordinator_HLR unless 

shown otheiwise. 

Signals to/ fromright are to/from 

HLRAResume uless shown 

otherwee 



K 





ELSE 



CCBS Idle 



A Idle 



MONITORING 



MONITORING 



Location_ 
Update 



No 




A Idle 



MONITORING 



IDLE 
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Figure 11.19: Procedure HLRA_CCBS_Check_lnteractions 
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1 1 .2 Destination Network Processes 
11.2.1 Procedures in GIVISC 

Figure 11.20: Procedure CCBS_MT_GMSC_Check_CCBS_Call 

This procedure checks from the lAM message whether the call is CCBS call. If that is the case the CCBS Call parameter 
is set to the Send Routeing Info message. This functionality shall be applied only to the initial call leg. The procedure 
initialises also the CCBS Possible variable as True, the variable is accessible to all CCBS specific procedures in the 
GMSC. 

Figure 11.21: Procedure CCBS_MT_GMSC_Check_CCBS_lndicators 

This procedure sets the CCBS_Call indicator to the outgoing 1AM message when needed. This functionality shall be 
applied only to the initial call leg. 

Figure 11.22: Procedure CCBS_MT_GMSC_Remove_Indicators_Store_FWT 

This procedure removes CCBS_Call indicator from the forwarded 1AM message and also stores the forwarding type. It 
also checks whether subscriber B can be target of CCBS Requests and stores that information for later use. 

Figure 11.23: Procedure CCBS_MT_GMSC_Remove_Indicators 

This procedure removes CCBS_Call indicator from the outgoing 1AM message. CCBS activation is not possible for this 
call because T-CSI modified destination address. 

Figure 11.24: Procedure CCBS_MT_GMSC_Check_CCBS_Possible 

This procedure contains the core logic to handle various interactions with CAMEL, OR and received Release message 
content. The procedure alters CCBS specific global variable CCBS Target which controls setting of the diagnostic field 
in the Release message towards the originating network. 

Global variables Reconnect and Resume Call are specific to CAMEL and OR interaction respectively. They are 
initiahsed and updated in the process MT_GMSC or MT_CF_MSC, refer to GSM 03.18. 
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Figure 11.20: Procedure CCBS_IVIT_GI\flSC_Check_CCBS_Call 
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Figure 11.21 : Procedure CCBS_MT_GMSC_Check_CCBS_lndicators 
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1 1 .2.2 Processes and procedures in HLR 

Figure 11.25: Block diagram of HLRB_processes 

Figure 11.26: Process HLRB_Request_Manager 

This process has the task of controlling the queue and determining whether requests to be processed are present in the 
queue or not. 

The process has two states "idle" and "active". In the "idle" state there are no "operative" requests in the queue i.e. there 
are only suspended requests or no requests at all. In the "active" state there is at least one "operative" request in the 
queue which needs processing. A transition from "idle" to "active" will trigger this process to start the process 
"HLRB_Recall_Manager". Only a transition from "active" to "idle" will result in this process stopping the process 
"HLRB_Recall_Manager" . 

Figure 11.27: Process HLRB_Request 

This process represents an individual CCBS request on the destination side. Reception of signals on the external 
interface (SSAP signalling) are handled by this process. 

Retention is handled by this process. The individual request is informed by the Recall manager process about the 
outcome of the CCBS Call. The individual request is in charge to decide on whether it will stay in the destination queue 
(retention) or not according to its data stored. 

T7 expiry is controlled by the individual request in that way, that it remembers T7 expiry when it is the selected request 
(i.e. a CCBS Recall has been initiated for this request). The event is detected after the CCBS Recall when retention has 
kept the request in the queue. 

Figure 11.28: Process HLRB_Recall Manager 

This process is in charge of the recall handling. It is started and stopped by the process "HLRB_Request_Manager" 
depending on whether there are operative requests in the terminating queue or not. 

As soon as this process is started, it will start the process "HLRB_Monitoring" and wait for a response from this 
process. The response indicates that user B is idle guarded i.e. a CCBS Recall can be initiated. Hence, the process asks 
the request manager for selection of an individual request from the terminating queue. 

When an individual process is selected, the process initiates a CCBS Recall via the individual request (since the external 
interface is tied to the individual request), starts T9 and takes over control of the blocking function while waiting for the 
CCBS Call. Control of blocking is done by sending the signal "Recall_Block" to process "HLRB_B locking". 

While waiting for the outcome of the CCBS Call, the process will be informed either by the selected individual request 
in the case of negative outcome (suspension or cancellation, both hidden to the process), or by process 
"HLRB_Monitoring" in the case the CCBS Call has reached the terminating PLMN. 

Figure 11.29: Process HLRB_Monitoring 

This process takes care of monitoring events received from MSCA'LR and detects potential conditions for initiating a 
CCBS Recall. 

The process is controlled by the "HLRB_Recall_Manager" process which was formerly in charge of detecting the recall 
condition. 

When the process is started, it invokes the monitoring function in the MSC/VLR and awaits the first event report. The 
process keeps track of the subscriber state changes by running a state machine which reflects the subscriber states. When 
there is a transition from subscriber state "not idle" to "idle", then T8 is started. As soon as T8 expires, the process 
changes state again in order to remember that the subscriber is now idle guarded and a recall could be initiated 

Whether a CCBS Recall is initiated or not depends on whether the process "HLRB_Recall_Manager" has asked for this 
information by sending a "B_Query" signal to the monitoring process. The process "HLRB_Monitoring" gives this 
information only if the "B_Query" signal has been received. This is done by sending the signal "B_Guarded" to the 
Recall Manager and it is only done once per request. The monitoring process keeps track on whether a query was 
received or not by appropriate state changes. 



GSM 03.93 version 6.1 .0 Release 1 997 97 TS 1 01 283 V6.1 .0 (1 998-07) 



As the monitoring process is in charge for the idle guard function, it also controls the blocking of incoming calls during 
the idle guard time (T8). Hence, when the recall manager process has sent a "B_Query" (i.e. a CCBS request needs to be 
processed) then the monitoring process starts the corresponding blocking along with T8. The blocking is only stopped if 
T8 does not expire. If T8 expires, then blocking is still needed for the following CCBS Recall. The responsibility for 
controlling the blocking (i.e. switching it off) is given to the recall manager process. 

Figure 11.30: Process HLRB_B locking 

This process controls the CCBS Call delivery reporting when the processes are in the proper state. This means that the 
reporting functionality of the outcome of the CCBS Call is not blindly triggered whenever there is a terminating CCBS 
Call. 

The process has three different states: "idle", "Blocking" and "Recall Blocking". The "Idle" state reflects the case when 
blocking is disabled. In the "Blocking" state all incoming calls are blocked (e.g. while T8 is running). The "Recall 
Blocking" state allows one CCBS Call to pass, which will trigger the CCBS Call delivery reporting in the MSC/VLR via 
the GSM 03.18 process "SRI_HLR". When this happens, the process will automatically change back to state "Blocking" 
as no other CCBS Call is expected for now. 

When the process has detected that destination B is idle, it will start the blocking. Hence, the blocking process will 
change state to "Blocking". As soon as the process "HLRB_Recall_Manager" has initiated a CCBS Recall, it will cause 
a state change in the blocking process to state "Recall Blocking". When the CCBS Call is received, "result = OK" 
indication in signal "SRI_Received_Ack" will trigger the reporting mechanism for CCBS Call delivery via a PRN 
request in the GSM 03.18 process "SRI_HLR" 

Figure 11.31: Procedure HLRB_CCBS_Check_Interactions 

This procedure checks whether the request is frozen due to the supplementary service interactions. 

Figure 11.32: Procedure CCBS_HandHng_HLR 

This procedure is called during Send Routeing Info message handling in the HLR. If blocking is active only CCBS Calls 
can proceed, others will fail with busy or forward indication. For CCBS Call CCBS Call Indicator is set to the Provide 
Roaming Number message. 

Figure 11.33: Procedure CCBS_Report_PRN_Failure 

This procedure is called if Provide Roaming Number returns an error. For CCBS call is then generated an internal call 
report. 

The handling of multiple requests in HLR B can be further clarified by the diagram shown in figure 1 1 .25. 
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Figure 11.25: HLRB_Processes 

Description of above signals 

Relation Originating Network and HLRB_Request_Manager 

CCBS Request : When the originating network attempts to activate CCBS, it sends a CCBS_Request message to HLRB 
Request Manager. 

CCBS Request Ack : When the HLRB_Request_Manager acknowledges the activation, it sends CCBS_Request Ack to 
originating network. 
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CCBS Reject: If the HLRB_Request_Manager does not accept the activation attempt, it sends CCBS_Reject to the 
originating network indicating long term or short term denial. 

Relation Originating Network and HLRB_Request 

CCBS Suspend : If the originating network suspends a CCBS Request, it sends CCBS_Suspend to HLRB Request. 

CCBS Resume : When a request that was suspended is now resumed, the originating network sends a CCBS_Resume 
message to HLRB Request. 

CCBS Cancel : When a request is cancelled in the originating network, it sends a CCBS Cancel message to HLRB 
Request. 

Remote User Free : HLRB_Request sends Remote_User_Free to the originating network to inform the originating 
network that destination B is now idle. 

CCBS Cancel : If a CCBS Request is cancelled in the destination network, HLRB_Request sends CCBS_Cancel to the 
originating network. 

TC END : If a CCBS Call is successfully delivered to destination B, then HLRB_Request ends the dialogue with the 
originating network by sending a TC_END message. 

Relation HLRB_Request_Manager and HLRB_Request 

Selection Request : Once destination B is idle guarded, then the HLRB_Request_Manager will select the first non- 
suspended request in the queue for processing by sending "Select_Request" to HLRB_Request. 

Inactive : When a CCBS Request is either suspended or unselectable due to the supplementary service interaction, 
HLRB_Request informs HLRB_Request_Manager so that the queue status can be updated. 

Re-Activated : When either a suspended CCBS Request is resumed or the supplementary service interaction with the 
request ends, then HLRB_Request informs HLRB_Request_Manager so that the queue status can be updated. 

Deleted : When a CCBS Request is cancelled, then HLRB_Request informs HLRB_Request_Manager so that the queue 
status can be updated. 

Relation HLRB_Recall_Manager and HLRB_Blocking 

Stop Blocking : When the Recall manager process is stopped by the Request Manager process or the Recall manager 
receives and 'End' signal from the Request manager, the Recall manager sends "Stop_Blocking" to HLRB_Blocking. 

Recall Block : When a "Send RUF" signal is sent to HLRB_Request, the HLRB_Recall_Manager also sends "Recall 
Block" to HLRB_Blocking so that one CCBS Call can be delivered to destination B, but other normal incoming calls 
are blocked. 

Relation HLRB Recall_Manager and HLRB_Request_Manager 

Select Request : On reception of a "B_Guarded" signal, the Recall manager sends "Select_Request" to the Request 
manager. The Request manager then selects the first non-suspended request in the queue for processing. 

Start Recall Manager : When a CCBS Request is successfully activated, the Request manager sends 
"Start_Recall_Manager" to HLRB_Recall_Manager which subsequently causes the recall manager process to start the 
monitoring process. 

Stop Recall Manager : The Request manager can stop the Recall manager process by sending a "Stop_Recall_Manager" 
signal 

Select Request Response : When the Request manager has selected a request for processing it sends a response to the 
recall manager causing the recall manager to initiate a CCBS Recall. 

Relation HLRB_Recall_Manager and HLRB_Request 

Send RUF : The Recall manager requests the individual process to send a Remote User Free indication to the originating 
network by sending a "Send_RUF" signal to the individual process. 
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Recall Report : The Recall manager informs the individual process of the result of processing a CCBS Recall by sending 
a "Recall Report" signal. 

END : When a CCBS Request is suspended or cancelled the HLRB_Request process sends an "End" signal to the Recall 
Manager process. 

Relation HLRB_Recall_Manager and HLRB_Monitoring 

Start Monitoring : When the Recall manager process is started by the Request manager process, the Recall manager 
sends "Start_Monitoring" to the HLRB_Monitoring process to request the status of destination B 

Stop Monitoring : When the Recall manager process is stopped by the Request manager process, the Recall manager 
sends "Stop_Monitoring" to the HLRB_Monitoring process. 

B Query : HLRB_Recall_Manager requests the HLRB_monitoring process to get informed when destination B has 
become idle guarded. 

Relation HLRB_Monitoring and HLRB_Recall_Manager 

B Guarded : HLRB_Monitoring informs the HLRB_Recall_Manager that destination B has become idle guarded. 
Call Delivery : HLRB_Monitoring informs the HLRB_Recall_Manager about the delivery of the CCBS call. 
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Figure 11.26: Process HLRB_REQUEST_l\flANAGER (sheet 1 of 3) 
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Figure 11.26: Process HLRB_REQUEST_l\flANAGER (sheet 2 of 3) 
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Figure 11.27: Process HLRB_REQUEST (sheet 1 of 6) 
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Figure 11.27: Process HLRB_REQUEST (sheet 2 of 6) 
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Figure 11.27: Process HLRB_REQUEST (sheet 3 of 6) 



GSM 03.93 version 6.1.0 Release 1997 



107 



TS101 283 V6.1. 0(1998-07) 



Process HLRB_Request 



Recall_Repo 
(Outcome) 



'FromHLRB_ 
'Recall_Manager 




NDUB 




True 



Operative 



Fai lure 



Success 



CGBS_ 
Cancel 



CCBS 

End 



ToHLRB_ 
'Request_Manager 



T9_ Expiry 



Reason:^ 
Out CD me 



CCBS_ 
Ca ncel 
(Re^on) 



4(6) 



Figure 11.27: Process HLRB_REQUEST (sheet 4 of 6) 
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Figure 11.27: Process HLRB_REQUEST (sheet 5 of 6) 
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Figure 11.27: Process HLRB_REQUEST (sheet 6 of 6) 
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Figure 11.28: Process HLRB_RECALL_l\flANAGER (sheet 1 of 3) 
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Figure 11.28: Process HLRB_RECALL_l\flANAGER (sheet 2 of 3) 



GSM 03.93 version 6.1.0 Release 1997 



112 



TS101 283 V6.1. 0(1998-07) 



Process HLRB_Reca II Manager 



Wait_For_ 
CCBS Call 



End 



Rom HLRB_ 
Request 



StopTS 



Stop_ 
Blocking 



B_Query 



ToHLRB_ 
Blocking 



ToHLRB_ 
Monitoring 



WaLFor_ 
B_Guaiided 



Call_Delk/ery , 
(Outcome) ^ 



Stop TO 



Recall_ 

Report 

(Outcome) 



FromHLRB_ 
-Monitoring or 
CCBS_Report_ 
PRN_Failure 



TO Expiry 



Outcomes 
T9 Expiry 



-To HLRB_Request 



Stop_Recall_ 
Manager 



Stop TO 



Stop_ 
Monitoring 



Stop_ 
Blocking 



Idle 



3(3) 



Rom HLRB_Request_ 
Manager 



^To HLRB__ 
Monitoring 



ToHLRB_ 
Blockhg 



Figure 11.28: Process HLRB_RECALL_l\flANAGER (sheet 3 of 3) 
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Figure 11.33: Procedure CCBS_Report_PRN_Failure 
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1 1 .2.2 Procedures in MSC/VLR 

Figure 11.34: Procedure CCBS_MT_MSC_Check_Forwarding 

This procedure is called to set the CCBS Target variable. That variable is used in later phase to set the correct diagnostic 
value to the Release message. 

Figure 11.35: Procedure CCBS_Handle_PRN 

This procedure is called to store CCBS call indicator when roaming number is reserved in the VLR. 

Figure 11.36: Procedure CCBS_lCH_Set_CCBS_Call_lndicator 

This procedure is called when VLR receives Send Info For Incoming Call message. If MSRN is related to the CCBS 
call, CCBS call indicator is set for call handling. 

Figure 11.37: Procedure CCBS_lCH_Report_Failure 

This procedure is called when CCBS call fails in the destination MSC. 

Figure 11.38: Procedure CCBS_ICH_Report_Not_Reachable 

This procedure is called when call fails in the destination MSC with special cause of Not_Reachable. On normal call 
Not_Reachable message is sent to the monitoring process, on CCBS call subscriber is reported being absent. 

Figure 11.39: Procedure CCBS_lCH_Handle_NDUB 

This procedure is called when call encounters NDUB condition in the destination MSC. It is a network option to 
forward the call or release the call. 

Figure 11.40: Procedure CCBS_ICH_Handle_UDUB 

This procedure is called when call encounters UDUB condition in the destination MSC. 

Figure 11.41: Procedure CCBS_ICH_Report_Success 

This procedure is called when CCBS call is successfully delivered in the destination MSC. 

Figure 11.42: Procedure CCBS_ICH_Set_CCBS_Target 

This procedure is called if when a call encounters busy condition in the destination MSC. If busy cause is NDUB and 
the user has elected to be target of CCBS requests, CCBS Target is set to True. 
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Figure 11.34: Procedure CCBS_MT_MSC_Check_Forwarding 
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Figure 11.35: Procedure CCBS_Handle_PRN 
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Figure 11.36: Procedure CCBS_ICH_Set_CCBS_Call_lndicator 
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Figure 11.37: Procedure CCBS_ICH_Report_Failure 
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Figure 11.38: Procedure CCBS_ICH_Report_Not_Reachable 
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Figure 11.39: Procedure CCBS_ICH_Handle_NDUB 
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Figure 11.40: Procedure CCBS_ICH_Handle_UDUB 
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Figure 11.41: Procedure CCBS_ICH_Report_Success 
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Figure 11.42: Procedure CCBS_ICH_Set_CCBS_Target 
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1 1 .3 Processes and procedures common in originating and 
destination network entities 

Figure 11.43: Process CCBS_Monitoring_VLR 

This process is responsible for monitoring the subscriber in VLR and also controls the MSC monitoring process. 

Figure 11.44: Process CCBS_Monitoring_MSC 

This process is responsible for monitoring subscriber in MSC. 

Figure 11.45: Process CCBS_Coordinator_HLR 

This process co-ordinates HLRA and HLRB monitoring interaction. Start and Stop Reporting messages are sent only 
once towards MSC, CCBS_Call_Report messages are directed to correct queue and Status information is distributed to 
both queues when needed. 

Figure 11.46: Procedure CCBS_Set_Diagnostic_For_Release 

This procedure is called to set the diagnostic field to the Release message. The diagnostic is set according to the internal 
CCBS Target variable. 

Figure 11.47: Procedure CCBS_Report_Not_ldle 

This procedure is called when either MO or MT setup is received or sent to the MS. It informs the VLR monitoring 
process that the MS is engaged with a call. 

Figure 11.48: Procedure CCBS_Report_MS_Activity 

This procedure is called when Process_Access_Request is successfully performed. It informs the VLR monitoring 
process and may cause transition to the Idle state. 

Figure 11.49: Procedure CCBS_Check_Last_Call 

This procedure is called when a call is ending. If the call is the last CC connection to the MS, that is reported to the VLR 
monitoring process. 
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Figure 11.43: Process CCBS_Monitoring_VLR (sheet 1 of 4) 
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Figure 11.43: Process CCBS_l\/lonitoring_VLR (sheet 4 of 4) 
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Figure 11.44: Process CCBS_IUIonitoring_IUISC 



GSM 03.93 version 6.1.0 Release 1997 



142 



TS101 283 V6.1. 0(1998-07) 



Process CCBS Coordinator HLR 



1(6) 



Sig nal s to / fro m left \ 
are to /from the VLR 
un less sh own 
Qthe rwis e 



ble 



From HLFW_ 
Monitoring 



Start_ 
Reporting 



From HLRB_ 
Monitoring 



Start_ 
Reporting 



CCBS_CalL 
>Report(Mode 
Outcome, 
Status) 



Note: CCBS_Call_ Report 
ncan exist on Aside without 
ongoing monrtoring in the MSC 



SeeGSM03.18 



ToHLRA_ 

Recall_ 

Manager 



Start_ 
Reporting 



Mon itorl ng 
A 



Start_ 
Reporting 



Monitoring 
B 




From subscrii^er 
d atah and II ng in 
HLR 



To HL RA_ 
Monitoring 



To HL RB_ 
Monrtoring 



Locatlon_ 
Update 



Continue_ 
Monitoring 



From HLRB_ 
iRequest_ 
Manager 



Locatlon_ 
Update 



Locatlon_ 
Update 



Keep the 
communication 
t)etween HLR and 



VLR 



Idle 



Figure 11.45: Process CCBS_Coordinator_HLR (sheet 1 of 6) 
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Figure 11.45: Process CCBS_Coordinator_HLR (sheet 4 of 6) 
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Figure 11.45: Process CCBS_Coordinator_HLR (sheet 5 of 6) 
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Process CCBS Coadinator HLR 
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Figure 11.45: Process CCBS_Coordinator_HLR (sheet 6 of 6) 



GSM 03.93 version 6.1.0 Release 1997 



148 



TS101 283 V6.1. 0(1998-07) 



Procedure CCBS_Set_Diagnostic_For_Re lease 
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Figure 11.46: Procedure CCBS_Set_Diagnostic_For_Release 
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Procedure CCBS_Report_Not_ldle 
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Figure 11.47: Procedure CCBS_Report_Not_ldle 
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Procedure CCBS_Report_MS_Activity 
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Figure 11.48: Procedure CCBS_Report_IUIS_Activity 
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Procedure CCBS Check Last Call 
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Figure 11.49: Procedure CCBS_Check_Last_Call 
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12 Information stored in the HLRs 

Note that a given subscriber may be both the originator and the target of CCBS requests; a given HLR may therefore be 
required to store both the data for HLR A and the data for HLR B against a given subscriber. 



12.1 Originating Network Data 



The following logical states are applicable for the CCBS service in the originating network (refer to GSM 03.11 for an 
explanation of the notation): 

Provisioning State Registration State Activation State HLR Induction State 

(Not Provisioned, Not Applicable, Not Active, Not Induced) 

(Provisioned, Not Applicable, Active and Operative Not Induced) 

The logical state shall be on a per subscriber basis and hence the same for all basic service groups. 

The HLR shall store the logical state of the CCBS service (which shall be one of the valid states listed above) on a per 
subscriber basis. The HLR shall store the following information for each CCBS Request that is successfully activated by 
subscriber A: 

- AddressOfB; 

Basic Service Group; 

- CCBS Call Information; 
Translated Number; 

Retention supported by destination network (if HLR A supports retention); 

- CCBS Index; 

- CAMEL Invoked. 

The HLR shall store for the served subscriber as the originator of CCBS requests: 
The parameter "Max Queue Size", 
This parameter takes a value in the range 1 to 5. 

12.2 Destination Network Data 

The following logical states are applicable for the CCBS service in the destination network (refer to GSM 03.1 1 for an 
explanation of the notation): 

Provisioning State Registration State Activation State HLR Induction State 

(Not Provisioned, Not Applicable, Not Active, Not Induced) 

(Provisioned, Not Applicable, Active and Operative, Not Induced) 

The logical state shall be on a per subscriber basis and hence the same for all basic service groups. 

The HLR shall store the logical state of the CCBS service (which shall be one of the valid states listed above) on a per 
subscriber basis. 

The HLR shall store the following information for each CCBS Request that is successfully activated against User B : 

Basic Service Group; 

Retention supported by originating network (if HLR B supports retention). 
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The HLR shall store on a per subscriber basis: 

The parameter "Number of terminating CCBS Requests" 

This parameter takes a value in the range 1 to 5. 

1 2.3 Transfer of information from HLR to VLR 

If the provisioning state for CCBS supplementary service is "Provisioned" then, when the subscriber registers on a VLR, 
the HLR shall send that VLR information about the logical state of CCBS supplementary service. 

If the logical state of CCBS supplementary service is changed while a subscriber is registered on a VLR, then the HLR 
shall inform the VLR of the new logical state of CCBS supplementary service. 

Both originating and destination network CCBS supplementary service logical states are updated independently of each 
other to the VLR. 
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1 3 State transition model 

13.1 State transition model for the CCBS service in the 
originating network 

Figure 13.1 shows the successful cases of transition between the applicable logical states of the CCBS service in the 
originating network. The state changes may be caused by actions of the service provider or the network. 



Provision 




Not Provisioned 

Not Applicable 

Not Active 

Not Induced 



Provisioned 

Not Applicable 

Active and Operative 

Not Induced 



Withdrawal 



Figure 13.1 : State Transition IVIodel for CCBS Service in the originating network 



13.2 State transition model for the CCBS service in the 
destination network 

Figure 13.2 shows the successful cases of transition between the applicable logical states of the CCBS service in the 
destination network. The state changes may be caused by actions of the service provider or the network. 

Provision 




Withdrawal 




Figure 13.2: State Transition IVIodel for CCBS Service in the destination network 
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13.3 State transition model for a CCBS Request 

Figure 13.3 shows the successful cases of transition between the applicable logical states of a CCBS Request. The state 
changes may be caused by actions of the served subscriber or the network. 

Each subscriber can be considered to have a set of n requests, where n is the maximum number of CCBS requests 
allowed for a subscriber as an originator. 



CCBS Request 




CCBS Recall 



CCBS Cancel 
CCBS Complete 



Figure 13.3: State Transition IVIodel for a CCBS Request in Originating Network 

On provision of the CCBS service, all requests transit to the "Start" state 
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CCBS Cancel 
CCBS Complete 



Figure 13.4: State Transition IVIodel for a CCBS Request in Destination Network 



13.4 Information stored in the VLRs 



Originating Network Data 

For the CCBS service in the originating network the VLR shall store the service state information received from HLR. 

Destination Network Data 

For the CCBS service in the destination network the VLR shall store the service state information received from HLR. 
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Annex A (Informative): 

Message flow diagrams showing a successful CCBS 

request 

The following message flow diagrams show a successful CCBS request. Destination B busy when request activated, 
subscriber A free when destination B becomes free (mobile-to-mobile). 
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Annex B (Informative): 

Status of Technical Specification GSM 03.93 
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of 

Technical Specification GSM 03.93: stage 2 CCBS 
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Version 


Comments 






no Phase 1 version 
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version 1.0.0 
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March 1998 


version 2.0.0 


to SMG#25 for approval 


March 1998 


version 6.0.0 


TS approved by SMG#25 for Release 97 
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version 6.1.0 


CR 03.93-AOOlrl (cat D) 
CR 03.93-A002r2 (cat F) 
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